Day 21｜Vibe Coding 的工作流程：先寫需求文件，再讓 AI 動手

今天開始進到本系列最後的部分了！前面二十天分享的是概念與技巧，接下來則是會記錄自己與Claude code協作一路開發的專案——個人版 LLM Router。

這個專案是用 vibe coding 的方式，跟 AI 一路做出來的，所以接下來分享的重點不是程式碼本身，而是整個開發過程裡的構思、判斷跟取捨。

今天先從最根本的工作方式開始——為什麼會養成「先寫需求文件，再讓 AI 動手」這個習慣。

為什麼先寫需求文件，才讓 AI 動手寫 code

這個習慣其實不是第一天就有的，而是踩了無數個坑後被「逼」出來的。

一開始跟 AI 協作開發時，跟多數人一樣：大概想清楚功能、架構與預期成果，稍微整理一下就直接下 prompt，一層一層往上疊加，出錯了再叫它修。但這種做法很快就撞牆了——模組邊界切割不清、產出用途含糊；一旦 AI 的實作方向開始走偏，整個專案就像脫韁野馬，很難再拉回原本設定的軌道。

後來意識到，傳統軟體開發流程的智慧在 AI 時代依然適用。在公司團隊協作中，PM 先出需求文件是為了對齊認知，工程師也能針對模糊處精準發問，同事間協作也是先確認規格才動工。

把這套流程搬到 AI 上甚至更關鍵。因為 AI 遇到沒講清楚的細節，不會像資深工程師一樣靠經驗補齊，而是會「自信地瞎猜」，猜歪了不說，還會順手寫出一堆不需要的功能，越補越亂。

先把需求寫成結構清晰的文字，除了幫自己釐清盲點，更是明確劃定每個模組的邊界，讓 AI 能基於全局做規劃，而不是邊做邊猜。

怎麼讓 AI 幫忙生出需求文件

需求文件不需要自己從零刻起，核心在於「借力 AI，但嚴格分工」：

先對焦，再整理：先跟 AI 說明模組與核心功能，接著請它用「互動式問答」反問細節。在來回討論中把盲點補齊，最後再由它整理成正式的需求規格。

下達最重要的緊箍咒：一開始就要明確指令——「現在只討論並產出需求文件，絕對不要動手寫 code」。必須強制把「定規格」跟「動手實作」切成兩個獨立階段，避免 AI 聊著聊著就自作主張把程式碼端出來。

關鍵技巧：一個模組一份文件，不寫巨型規格

不建議把整個龐大系統塞進同一份大文件裡，而是堅持「一個模組一份文件」。理由很單純：

• 精準控場：模組邊界清楚，開發就能一塊一塊逐步推進，進度好追蹤、功能好驗收
• 降低耦合度：未來維運、擴充功能或抓 bug 時，改動範圍能被嚴格框在特定模組內，不至於牽一髮動全身

小結

從「邊做邊修」到「先寫需求文件再開發」，這個轉變不是一次到位的頓悟，而是被模組邊界不清、AI 失控難收拾這些真實踩過的坑逼出來的，再加上本職工作養成的「先對齊需求、再動手」的直覺，兩者合在一起，變成現在這套跟 AI 協作的方式。

接下來幾天，會照著這些需求文件，一個模組一個模組，分享這個 Router 專案在構思與開發過程中的實際思路。明天先從第一個模組開始。